Rolling Releases (bleeding edge) about neomutt

[grobian]

From Gentoo's point of view it would be ideal if we could git pull the tip of the integration repo. We have many "version 9999"s like this that just compile latest or the head of a branch.
But this only makes sense if it allows our users to contribute back more easily to the development of NeoMutt. If not, the monthly cycle is fast enough updates IMO.

[alexpearce]

The formula supports installed the ‘HEAD’ version, which is currently defined as the neomutt branch.

$ brew install neomutt --HEAD

This command takes the same arguments as without the --HEAD flag, like --with-sidebar-patch. If there's another branch that would be better suited, we can switch to that.

[shioyama]

For arch it's easy, we already have neomutt-git for exactly this purpose.

[flatcap]

That's good that it's easy.
The question is: What do you want from it?

• Bug fixes?
• Features in devel branches?
• Mutt/default latest commits?

[flatcap]

But this only makes sense if it allows our users to contribute back more easily to the development of NeoMutt.

Absolutely.
That's why I'd favour seeing the devel branches (slightly unstable stuff) in the git branch.

In return, the users would get the highest priority support.
With one condition: the fix could include disabling the feature (temporarily).

[flatcap]

I've added a 'git' tag to the issue labels.

A typical bug workflow might be:

• BUG: newly raised problem
• GIT: fix has been committed to git branch (rolling release)
• RELEASE: the fix will appear in the next, tagged, NeoMutt release

The same would be true of enhancements, but there may be a bigger gap between GIT and RELEASE.

[flatcap]

@grobian @alexpearce @shioyama @riesebie
Ping?

A week back I asked:

The question is: What do you want from it?

• Bug fixes?
  • This is easy. These commits would be destined for [neomutt] soon.
• Features in devel branches?
  • This would be useful for me, if the cutting edge people tested new features. Unfortunately it means you'd need a separate branch.
• Mutt/default latest commits?
  • Doable, but lots of work. I'm going to create a set of [unstable/X] branches soon which would be branched from [mutt/default]. I need to figure out how the upstream changes would affect the features. This option would give you advanced features like "Sidebar-on-Right". However, these branches might not get updated often (unless I get help).

[alexpearce]

I don't think I've grokked the neomutt branching model well enough to answer this question yet. How is what is being proposed different from the current neomutt branch? That's what Homebrew users can use now if they specify --HEAD when installing.

Would require an additional branch, one where, say, bug fixes get merged into before then being merged in to neomutt?

[riesebie]

The best would be to have a stable and a devel branch.The model to keep the feature patches in seprearted branches sounds good. For the actual Debian packages I'll follow neomutt/neomutt branch which is mostly the "bleeding edge" branch? The stable branch should contain the official releases which I want to switch over when I upload neomutt to Debian/sid.

[grobian]

+1 on not yet grokking the neomutt branching model
Thinking about this, and the possible complexity, how about release often instead? I want the fixes from upstream, plus features if they seem finished. I have no problems mixing them in releases, since most features are optional add-ons that shouldn't bother people that don't want them.

[flatcap]

Ah, sorry guys. As with all the best (crazy) plans it make sense in my head.
I'll draw a diagram. All will become clear.

[flatcap]

OK, brain dump complete, see #61(NeoMutt Branching Explained).

There are three models:

• Periodic Release -- This is what I used to do
• Release with Hotfixes -- This is where we are
• Advanced -- I'd like to tempt you with shiny things :-)

---

@alexpearce

require an additional branch

Yes. In the diagrams I've called it "Advanced"

---

@riesebie

stable and a devel branch

The NeoMutt branch should be stable. That way the hotfixes would just be in case of emergencies.

The Advanced branch would be the "unstable" branch, but there's no need for it to be dangerous. We wouldn't merge feature commits until they look solid enough.

---

@grobian

possible complexity

It's not too bad, to be honest. Even the Advanced workflow.

how about release often instead

Until I can automate all my release processes, this is a major PITA.
If I can nudge you guys to Advanced, I could make fewer releases :-)

I want the fixes from upstream, plus features if they seem finished.

I don't want to sound pushy, but I'd really like some guinea pigs for the devel features.
The new features wouldn't be merged into Advanced until they were relatively stable (or at least config-disable-able).

[grobian]

I don't want to sound pushy, but I'd really like some guinea pigs for the devel features.
The new features wouldn't be merged into Advanced until they were relatively stable (or at least config-disable-able).

Isn't that exactly what Gentoo is trying to do?

[flatcap]

some guinea pigs for the devel features.

Isn't that exactly what Gentoo is trying to do?

Sorry, that comment was more directed at the others.

Your adoption of the new window changes puts you into workflow category 4 (undocumented :-)
This means that supporting Gentoo is always going to be more work.

I'd like to fit you into the Advanced workflow, but I don't know how.
I've got some diagrams, on paper, but they're not pretty.

[grobian]

Cool. I guess I'm looking for that too.

Just thinking out loud here, what could be done as well, is for Gentoo (but I can imagine other dist doing the same) to just have a branch/clone of their own, from which they pull neomutt work. I don't mind having it in the neomutt repo, but in the same way I don't mind having it gentoo hosted, or on github under the gentoo project. The idea is that in that way, I can apply the patches that Gentoo historically has had and maintain a branch, based on neomutt, yet not forcing others to use the same patches. The main aim would be to on the long term reduce this as much as possible, and end up with a branch that more or less /is/ neomutt.