As we try to work towards better bugzilla and redmine component definitions
and relations, I keep finding myself wishing I could use redmine for both
foreman and katello issues together.
For example, several dev teams are experimenting with redmine "versions"
for their sprints[1]. I don't think that a single version can include
issues from both foreman and katello projects. If katello was a subproject
of foreman, though, then teams could bring any issue into their sprint view.
Is there a case for keeping katello separate any longer, or can we combine?
I think having everything under one tree makes sense. Long-term, the
goal is to turn
Katello to not feel like a separate project, but rather an extension.
+1
Of course I'm not aware of some possible consequences if there are any?
– Ivan
···
On Tue, Aug 2, 2016 at 3:56 PM, Tom McKay wrote:
> As we try to work towards better bugzilla and redmine component definitions
> and relations, I keep finding myself wishing I could use redmine for both
> foreman and katello issues together.
>
> For example, several dev teams are experimenting with redmine "versions" for
> their sprints[1]. I don't think that a single version can include issues
> from both foreman and katello projects. If katello was a subproject of
> foreman, though, then teams could bring any issue into their sprint view.
>
> Is there a case for keeping katello separate any longer, or can we combine?
>
> [1]
> http://projects.theforeman.org/projects/foreman/roadmap#Team_Ivan_Iteration_1
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> Is there a case for keeping katello separate any longer, or can we combine?
Because it's a plugin? And plugins have its own release cadence, own
planning (Release versions, Target versions) and Categories. I don't see
enough benefits of merging when I consider all the above.
I don't know, I would not like to see Discovery project merged into the
Core. I'd like to keep all plugins separate.
> For example, several dev teams are experimenting with redmine "versions"
> for their sprints[1]. I don't think that a single version can include
One more thing. This will pollute Target versions, I don't like this.
Can't we simply use Issue trackers for that? Redmine is quite good in
creating trackers and associating it. Also, it creates nice place for
conversation about the sprint.
On Tuesday 02 of August 2016 17:36:53 Ivan Necas wrote:
I think having everything under one tree makes sense. Long-term, the
goal is to turn
Katello to not feel like a separate project, but rather an extension.
+1
Of course I'm not aware of some possible consequences if there are any?
-- Ivan
On Tue, Aug 2, 2016 at 3:56 PM, Tom McKay wrote:
As we try to work towards better bugzilla and redmine component
definitions
and relations, I keep finding myself wishing I could use redmine for both
foreman and katello issues together.
For example, several dev teams are experimenting with redmine "versions"
for their sprints[1]. I don't think that a single version can include
issues from both foreman and katello projects. If katello was a
subproject of foreman, though, then teams could bring any issue into
their sprint view.
Is there a case for keeping katello separate any longer, or can we
combine?
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I'm suggesting that we make katello a subproject of foreman. There are
already plugin subprojects (eg. discovery). By moving it under the single
parent project other redmine features become usable (eg. loading a sprint
with issues from both foreman and katello).
···
On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal wrote:
Is there a case for keeping katello separate any longer, or can we
combine?
Because it’s a plugin? And plugins have its own release cadence, own
planning (Release versions, Target versions) and Categories. I don’t see
enough benefits of merging when I consider all the above.
I don’t know, I would not like to see Discovery project merged into the
Core. I’d like to keep all plugins separate.
You do realize that every other plugin except Katello is under the foreman
project in redmine, correct?
David
···
On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal wrote:
Is there a case for keeping katello separate any longer, or can we
combine?
Because it’s a plugin? And plugins have its own release cadence, own
planning (Release versions, Target versions) and Categories. I don’t see
enough benefits of merging when I consider all the above.
I don’t know, I would not like to see Discovery project merged into the
Core. I’d like to keep all plugins separate.
>> Is there a case for keeping katello separate any longer, or can we combine?
>
> Because it's a plugin? And plugins have its own release cadence, own
> planning (Release versions, Target versions) and Categories. I don't see
> enough benefits of merging when I consider all the above.
Just to make sure we are on the same page, we are not talking about
merging it into Foreman and not having the Katello sub-project,
it's about Katello having it's own tree not being in the Foreman
tree [1]. So effectively it's just a moving it to the similar place where
the rest of plugins is, rather than treating it specially.
>
>
>
> > Is there a case for keeping katello separate any longer, or can we combine?
>
> Because it's a plugin? And plugins have its own release cadence, own
> planning (Release versions, Target versions) and Categories. I don't see
> enough benefits of merging when I consider all the above.
>
> I don't know, I would not like to see Discovery project merged into the
> Core. I'd like to keep all plugins separate.
>
>
> I'm suggesting that we make katello a subproject of foreman. There are
> already plugin subprojects (eg. discovery). By moving it under the
> single parent project other redmine features become usable (eg. loading
> a sprint with issues from both foreman and katello).
>
+1 for moving it into a subproject and treating it the same as other
plugins.
···
On 08/03/2016 06:30 PM, Tom McKay wrote:
> On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal > wrote:
> > For example, several dev teams are experimenting with redmine "versions"
> > for their sprints[1]. I don't think that a single version can include
>
> One more thing. This will pollute Target versions, I don't like this.
>
> Can't we simply use Issue trackers for that? Redmine is quite good in
> creating trackers and associating it. Also, it creates nice place for
> conversation about the sprint.
>
> An example of such a tracker:
>
> Tracker #10294: PXEless discovery feature - Discovery - Foreman
The problem with this approach is that it's hard to create a team
backlog (you create a giant tracker?), plus tracker issues don't allow
you to prioritize what do you do in each sprint.
With target versions, you can easily gather the stuff the team has done in a
sprint (automatically), see what's 'ready for testing' and should be
done in the next sprint, and you can prioritize your backlog of redmine
issues.
Also the redmine-backlogs plugin doesn't integrate with that - http://projects.theforeman.org/rb/master_backlog/ - which makes
prioritization and moving stuff from one sprint to another easier. With
a tracker moving stuff from sprint to sprint would mean creating a new
tracker?
+1 to less separation of the two projects in our overhead organization of
issues/features.
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
···
On Wed, Aug 3, 2016 at 4:08 AM, Marek Hulán wrote:
+1 for moving into Foreman project subtree
--
Marek
On Tuesday 02 of August 2016 17:36:53 Ivan Necas wrote:
I think having everything under one tree makes sense. Long-term, the
goal is to turn
Katello to not feel like a separate project, but rather an extension.
+1
Of course I'm not aware of some possible consequences if there are any?
-- Ivan
On Tue, Aug 2, 2016 at 3:56 PM, Tom McKay > wrote:
As we try to work towards better bugzilla and redmine component
definitions
and relations, I keep finding myself wishing I could use redmine for
both
foreman and katello issues together.
For example, several dev teams are experimenting with redmine
"versions"
for their sprints[1]. I don't think that a single version can include
issues from both foreman and katello projects. If katello was a
subproject of foreman, though, then teams could bring any issue into
their sprint view.
Is there a case for keeping katello separate any longer, or can we
combine?
--
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> The problem with this approach is that it's hard to create a team
> backlog (you create a giant tracker?), plus tracker issues don't allow
> you to prioritize what do you do in each sprint.
Backlog = whole RedMine (all Feature items that are not associated with
any "sprint" tracker).
> With target versions, you can easily gather the stuff the team has done in a
> sprint (automatically), see what's 'ready for testing' and should be
> done in the next sprint, and you can prioritize your backlog of redmine
> issues.
Indeed that's nice, but that was created for version management, not
scrum management.
> Also the redmine-backlogs plugin doesn't integrate with that -
> http://projects.theforeman.org/rb/master_backlog/ - which makes
> prioritization and moving stuff from one sprint to another easier. With
> a tracker moving stuff from sprint to sprint would mean creating a new
> tracker?
Yes, I mean exactly that. But no moving from "backlog", see above.
And this plugin - it kills our instance the moment we start drag and
dropping.
This whole scrum game miss one particular aspect - agility.
Please, can we please not create these crazy "backlogs" and the dance
around and just use RedMine as it was design for? Otherwise we will be
doing nothing but tossing tickets from backlog to backlog.
Put an item on "backlog" = create new Feature, NEW state
Put it on "sprint" = associate with feature issue (*)
Resolve issue, set Target Foreman version we ship it into
Profit!
(*) or use Target version if you really think it's any benefit
> Please, can we please not create these crazy "backlogs" and the dance
> around and just use RedMine as it was design for? Otherwise we will be
> doing nothing but tossing tickets from backlog to backlog.
The idea is to do that in 30m or so every two weeks
> * Put an item on "backlog" = create new Feature, NEW state
>
> * Put it on "sprint" = associate with feature issue (*)
>
> * Resolve issue, set Target Foreman version we ship it into
>
> * Profit!
This is what we've been doing for some time, the process is fine but how
can you prioritize a backlog of 6488 open issues? If the answer is
adding the ones we think are most important to an etherpad, it's
Pruning the search results to only show 'categories' owned by a
team or certain plugins, isn't a good solution for getting less issues,
as that field isn't that reliable & still returns 1000s of issues
I'm all open to ideas that allow us to have a concise backlog we can
prioritize from
